[レポート] COP201 How Discovery increased operational efficiency with AWS observability #reinvent #reinvent2022

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

セッション名 : How Discovery increased operational efficiency with AWS observability

概要(機械翻訳) : このセッションでは、ログ、メトリクス、タグなどの運用データの取り込み、処理、保持、計測、分析、可視化、およびガバナンスを管理するために、AWS上にまとまった集中型プラットフォームを構築し、Discovery社がどのように観測可能性プラットフォームを近代化したかをお聞きします。さらに、開発者のエクスペリエンスを向上させ、柔軟性を高め、組織の財政的責任を改善する大規模な観測可能性プラットフォームをAWS上に構築する方法について学びます。

スピーカー :
Marc Chene, Open Source Observability - Product and Engineering Lead, Amazon
Tom Leaman, Director of Observability & SRE, Warner Brothers Discovery
Karthik Rengasamy, Solutions Architect, AWS

レポート

最初は Tom Leaman 氏の登壇です。

Observability at WBD

オブザーバービリティとは何か？をランダムにエンジニアに尋ねると無表示になるか標準的な定義を答えるでしょう。
WBD のオブザーバビリティの定義については、統合であると考えています。
エコシステムに関連するすべての運用に関連するデータのロギング、メトリクスとトレースのみならず、コストのようなもの、組織のコンセプトのようなものも含まれます。

Where we started

2021 年にさかのぼる過去1年半の間に、私たちは確かに大きな進歩を遂げました。
1年半前は技術もツールセットも断片的でした。ラグやラベルの命名規則はなく、観測可能なツールを6つ以上使用していました。

Operation metadata specification

解決策に移りましょう。最初の、そして主要なターゲットは運用データのクリーンアップと一貫性の確保です。
私たちがまず優先したのは、運用辞書や専門用語を定義することでした。
技術的なエコシステム全体を説明するために使うもので、私たちはこれを operational metadata (OMD) と名付けました。
OMDの目標は、いくつかの質問に答えることでした。

まず第一に、そのサービスは何をするものなのか？
私たちは3層の機能階層を導入し、私たちのサービスが何に関連しているかのガイダンスを提供できるようにしました。

画面上では広範なプラットフォームに提供されているバックエンド・ログ・サービスの完全な分解を見ることができます。
最上位にはビジネス・サービスという用語があります。これは、観察可能性などの機能を高レベルでまとめたものです。
中間層では追加のグループ化とより細い粒度を提供します。ロギング、メトリクス、トレース、サービスとしての可視化などが該当します。
最後の層では OMD コンポーネントに分解されます。 私たちの考えるコンポーネントとは、ビジネス機能を提供する特定のマイクロサービスや共通のライブラリ、プラットフォームのことです。

Standardizing operational metadata (OMD)

私たちは分類法を定義し、進化させることができるように設定しました。
次に OMD の組み込み方を考えました。手動で更新するスプレッドシートにしたくなかったのです。
OMD はサービスの開始時、または再稼働時に組み込まれるべきという結論に達しました。

コード内に OMD を保存し、リポジトリに配置します。
CI/CD プロセスのなかでコンポーネントやサービスに自動的にタグ付け・ラベル付けされ、多くの情報を結合するために役立ちます。

Establishing order

プロジェクトマネージャーやリーダーなどコードリポジトリに入らない人達のために、毎日 24 時間ごとに GitHub リポジトリのスクレイピングジョブを実行し、設定からデータを取得して Amazon Aurora PostgreSQL データベースに格納します。
Aurora と Grafana のデータソース接続により人々がサービスカタログ全体を理解できるようにしています。

Tenets for change

オブザーバビリティ領域で解決できていなかった問題は、使用する技術の多さです。
この問題を解決するために、私たちが行ったことは、いわばすべてを支配する1セットの観測可能なツールを採用する方法について、一連の条件を設定することでした。
最初の条件は、自分たちのデータを自分たちで所有することです。
データに簡単にアクセスし、移動させることができるようにしたかったのです。
私たちはオープンソースを選択しました。多くの開発者がオープンソースの知識を持っており採用しやすかったこともあります。
さらに、バックログやロードマップの観点からも、オープンソースのプラットフォームやテクノロジーは、必ずしも特定のベンダーのニーズではなく、エンジニアリング・コミュニティによって動機づけられている傾向があります。

また、コスト管理のためにユースケースを分離し、異なるタイプのユースケースが互いに干渉し合うことで発生する爆風によるリスクを低減させたいと考えていました。

私たちは法規制データを扱っているので常にこの点を考慮しなければなりませんでした。

AWS パート

彼が使っている AWS サービスの詳細をお話します。

Amazon Managed Service for Prometheus はコンテナとコンピュータ環境から様々なメトリクスを取得します。
Amazon Managed Grafana は可視化エンジンです。

AWS のマネージドオープンソースを選択する理由は4つあります。
- 本番ワークロードに対応した拡張性 - 耐久性 - 他 AWS サービスとのシームレスな統合 - オープンソースの互換性

Amazon ではオープンソースの標準を採用しています。どのようにすれば、オープンソースをデプロイして使用しているビルダーの生活を向上させることができるかを考えています。
AWS はオープンソースコミュニティの思想リーダーであり良き世話係であり続けることが重要です。

セキュリティ面の新機能では、Amazon Managed Grafana は VPC に接続することで適切なレベルのセキュリティを維持することが可能です。

スケール面の新機能では、Amazon Managed Service for Prometheus はワークスペースあたり2100万個のアクティブ時系列メトリックスを提供します。Amazon Managed Grafana でも同様に、ワークスペースごとに最大1万人のユーザーをサポートできるようになりました。

Single pane of glass の面では、eks observabilityというワンステップのオンボーディングを公開しています。

Amazon OpenSearch Service は OpenSearch とダッシュボードを簡単にデプロイし運用・拡張できるマネージドサービスです。

Anatomy of logging-as-a-service

Tom Leaman 氏の再登場です。

私たちは logging-as-a-service をテンプレート化する必要がありました。
まずデータ収集に fluentd を選びました。次に、データ収集を実際のデータ同期自体から抽象化したいと考えました。そのために、Kinesis を使用してイベントストリーミングパイプラインを OpenSearch と S3 に提供しました。
これにより、OpenSearch のインデックス作成に関する問題やバックアップの場合に高い信頼性を確保できるだけでなく、将来的にはイベント駆動型アーキテクチャのための道を開くことができます。

Anatomy of metrics-as-a-service

現時点では Grafana エージェントに頼っていますが、次のステップとして、Open Telemetry、特に AWS Distro for OpenTelemetry を検討しています。
全てのデータは Relatable でなければなりません。メトリクスへの問い合わせはメトリクスそのものだけではなく関連するラベルも取得できるようにしています。

Scaling Operations

プレゼンテーションの中でも魅力的なスライドですが、スケーラビリティに関連する非常に重要なスライドでもあります。
以前はロギングデータストアからデータを返すのに10秒から20秒近くかかっていました。OpenSearch を採用しプラットフォームに投資しサービスとしてロギングするようになってからは、データを最大12TBまで増やし平均クエリ時間を20ミリ秒まで短縮しました。
日次で生成されるメトリクスの数はかなり少なくなっていました。現在では、本番環境で 1 日あたり約 730 万のメトリクスを生成しており、遠くない将来に約 5,000 万から 6,000 万まで増加させる計画です。
1日あたり約10万件のアラートを発行し、アラート関連のクエリーや標準的なダッシュボードを実行しています。

Scaling Insights

どのようなクラウドリソースがあるのかを簡単に理解できるよう高度に自動化されたカタログが必要でした。
kubernetes リソースとクラウドリソースをすべてスクレイピングしてデータを抽出します。それを S3 に取り込み、少なくとも24時間以内に最新のデータを取り出せる状態にします。

The Observability Platform

私たちは5～6種類の logging-as-a-service を導入し、それまでに使用されていた複数のツールを削除しました。

まず、インフラストラクチャーカタログですが、このデータはすべて S3 から供給されており、これは Athena を使ってクエリされ、Athena データソースプラグインを使って Grafana で可視化されています。

運用ダッシュボードは、Amazon managed service for Prometheus と OpenSearch を組み合わてデータを取得し150 以上のメトリクスとログを可視化しています。
スクリーンショットのような要約表示から自分たちのサービスに関連する詳細表示まで指一本動かすことなく見ることが可能です。

私たちは CI/CD のダッシュボードも提供しています。ダッシュボードを見て CI/CD プロセスで何が起こったのかを簡単に確認することが可能です。

そして最後に、すべてを結びつけるのがサービスカタログです。単一のサービスに関する完全に統一されたビューが提供され、必要なすべての情報を指先で確認できるようになります。

所感

大規模なシステム、非常に多くのシステムを管理する組織がどのようにして運用を最適化していったのかを具体的かつ詳細に説明してくれました。

• システム内の各リソースやコンポーネントを識別可能にするためのメタデータ (タグやラベル) を付与する
• メタデータの付与はリソース作成時に自動的付与すべき
• 使用する技術要素の多さはときに問題になる
  • 観測ツールの統一
• 運用のサービス化
  • logging-as-a-service
  • metrics-as-a-service

以上、吉井 亮 がお届けしました。